Published: Thu 03 September 2026
By Dave Page
In InfoSec .
tags: dns
Introduction
Recently, a company's website was
hijacked
and used to serve malware, with a legitimate-seeming TLS certificate. The
hijack didn't touch the webserver itself. Instead, it attacked the routing that
directs traffic towards the server. I'm going to describe how it happened and
how you might protect against it.
Let's say you go to visit my website at https://example.com/. First, your
computer looks up the IP address associated with the site, and tries to connect
to that address - first via your house's router, then via your ISP's router,
then via some other routers...
Each router is basically a multi-armed sign-post which says "If you're heading
towards this network, go down this piece of fibre optic. If you're going to
that network, use that fibre", and so on. Each router decides where its
signs point based on messages which are shared between routers.
It's occasionally possible for a powerful adversary to send out fake router
messages, which means that routers start sending traffic the wrong way. Let's
say that Mallory has done this, and your traffic intended for my domain can end
up at her server instead!
TLS Certificates
When your traffic arrives at Mallory's server, because it's using HTTPS, it'll
be expecting a TLS certificate that it can trust. So Mallory will need to
generate a trusted certificate. The standard way to do this is via LetsEncrypt,
a trusted Certificate Authority which will hand out TLS certificates to people
who can prove they have some level of ownership of a matching domain name.
We know that Mallory can route traffic intended for my domain name and its IP
address to her own server. Provided her router hack is comprehensive enough to
affect LetsEncrypt, she can use the http-01 method to assert that she can
control content on her impersonating server, and LetsEncrypt will give her a
TLS certificate.
Her server returns that certificate to your browser and you go on looking at,
or putting data into, a malicious website, none the wiser. You even get a nice
padlock in your browser to tell you that you're secure!
Stopping Mallory with CAA
How do I stop Mallory from doing this? I can assert who is allowed to issue
TLS certificates for example.com using a CAA record.
I could choose to pay for TLS certificates from Digicert, and tell the Internet
that only Digicert is alowed to issue TLS certificates for our domain. This
just requires me to set a CAA issue record of digicert.com. Then we can
rely on Digicert's authentication systems that will let me sign certificates
but not Mallory.
example.com. 3600 IN CAA 0 issue "digicert.com"
But that costs money, and I'm a cheapskate, so I want to use LetsEncrypt. But
if I allow LetsEncrypt to issue certificates, then Mallory can generate them
for my server if she hijacks the routing tables!
ACME Client Accounts
When you use an ACME client such as lego to
get a certificate signed by LetsEncrypt, an account is used. This happens in
the background, and I'd never noticed it before! Hiding somewhere in your ACME
client will be an account URI, and a private key used for authentication to the
server.
For lego, the account URI is stored in a file called account.json; for
Traefik it's in acme.json. You may have multiple URIs for multiple accounts
depending on how you've configured your client, so pick the one which matches
your domain!
You can specify two things in your CAA record: that only LetsEncrypt is allowed
to generate TLS certificates for your domain, and that only a specific
LetsEncrypt account can do it, by using the accounturi parameter.
example.com. 3600 IN CAA 128 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/99999999"
Note that I've changed the 0 to 128 in the CAA record. This means "if you don't
understand any directive, don't issue the certificate" and protects me against
typos in the record.
Now only LetsEncrypt account 99999999, authenticated by its key, is permitted
to generate TLS certificates for example.com. Any other issuer, or any other
LetsEncrypt account, should generate an error.
In my case I have two ACME clients - lego generates the TLS certs used by my
mailserver, and Traefik generates the certs used by my webserver. This isn't a
problem, I just add two CAA records for the same domain, with different URIs.
Finally, you can add a CAA iodef record, which means that if somebody
unauthorised tries to generate a certificate, you should be notified:
example . com . 3600 IN CAA 0 iodef "mailto:abuse@example.com"
UPDATE : I have learned that LetsEncrypt does not support iodef
notifications .
Sidenotes
There's also a CAA issuewild record which allows you to set separate policies
for wildcard TLS certificates. And you can also specify a validationmethod
parameter which limits which ACME method, such as HTTP or DNS, can be used to
validate ownership of a domain.
Another possible attack for Mallory would be to divert the route to
example.com's nameservers. That way she could not only redirect example.com
to any IP she wanted, she could also provide whatever CAA records she wants to
make sure the TLS cert was issued. However, this can be defeated using
DNSSEC, which uses a chain of digital signing from the root servers through
to my registrar. LetsEncrypt should be able to spot the unsigned or mis-signed
DNS records and refuse to issue.
Summary
How likely is this attack? Not very, for me - I'm not likely to have someone
try and hijack traffic to my random self-hosted server, because I'm not that
interesting to the kind of people who have the resources to do this.
It's also not something you have to worry about too much if you're, say,
connecting to a random wifi network. It's trivial for the provider of that
network to carry out routing attacks on your traffic to PayPal or Facebook or
whatever. But they won't be able to get a valid TLS certificate issued for
those domains, so you'll get a browser error. And thanks to another safety
technology called HSTS, you won't be able to bypass that error!
After I set up CAA records, I tried generating a certificate using a different
LetsEncrypt account:
2026 - 09 - 03 T22 : 03 : 30.812835274 Z ERROR Error error = "obtain certificate: resolver: one or more domains had a problem: [example.com: invalid authorization: acme: error: 403 :: urn:ietf:params:acme:error:caa :: While processing CAA for example.com: CAA record for example.com prevents issuance]"
I have however not yet received an email from LetsEncrypt despite my iodef
record.
At my job, we have websites which are used to transfer personal data, and I'll
be considering whether CAA records are an appropriate control to prevent this
kind of attack.